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CROSS-REFERENCE TO RELATED APPLICATIONS 
This appHcation claims the, benefit of U.S. Provisional Patent AppKcation No 
60/234,016. filed September 20. 2000, which is incoiporated herein by reference. 

FIELD OF THE INVENTION 
The present invention relates genemUy to data commnnicalions, and specifically to 
video and voice communications over electric power lines. 

BACKGROUND OF THE INVENTION 

Datacommunicationsusingresidential power lines are knownintheart Anadvantage 
of usmg the lines is that only peripheial infiastructure needs to be added to the existing power 
bnes m order to transmit and rec^ve the data communications. With appropriate modems, 
power lines can be used to cany all the types of data traffic that are currently earned on local 
area networics (LANs), wide area networks (WANs) and internets, including real-time voice 
and video. Among the disadvantages of using power lines are high attenuation and the high 
level of interference on Ihe lines, such as voltage spikes and Gaussian noise. These 
characteristics impose limitations on the available bandwidth and reliability of power line 
communications, which should be taken into account in the data services that are o^ over 
power line networks. 

a. paokef n«woAB such =5 the Latemcf. the Real-time Itanspor, Iteto«,l (RTP) i. 
commonly ,«ed to cany real-time mtUtimedia traffic, such as video and voice. Hds pmt«„I i, 
descnbed by Sh«l^e et al., in .-RTP. A T^nsport Protocol for R«U.11m. Applica.l«„ " 
published by the Network Working Group of the latemet E.gin«dng Task Pore (Bm „ 
Request for Comments (RPO 1889 (1996), which is incotporated h«ein byr«fc,en=e. Rpc 
1889 specifies a fonnat for RTP packets that inotodes . 12*yt= RIP h«rier «.d a 20-bvt. 
payloa4 which are canied together a. U„ paylo., „f a User Datagram ProtocoMnteme, 
Protocol (UDP/IP, data packet The RTP header include. . mm*« «rf time shunp 

whtch increase by at^ Som on. packet to the next in a RTP stream, abng with a fixed' 
synchronization source identifier (SSRQ field. Most of the oflrer Adds and flag, in the RTP 
header change ra^ly, if at all. m the com., of a RIP se»i„. RTP i. com..cfi„^^, 
W>P. m that RTP pack«s are streamed eontin«msly fiom the some, to th. 



1 



to 02/25822 



i 



1 



Page 4 of 37 



15 



WO 02/25822 PCT/IIX)l/00872 

destination, with no provision for veri^ that the packets have reached their destination 

intact. . 

The ovediead of RTP packets is a cause for concern when mnltimedia traffic is to 

be carried over low-bandwidth networks. The RTP. UDP and IP headers of a single packet 
5 add up to 44 byt^ (compared to the 2(M>ytepayload). The data link header (such as Ethernet) 
and additional signaling used for telephony ^Ucations. can easily add another 40 bytes, 
leaving only 20% of the channel bandwidA for the actual data. Jn response to this concern. 
Casner et al. suggest a method for RTP header compression on a link-by-link basis in IETF 
RFC 2508. entitled "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" (1999). 
10 which is incorporated herein by reference. This method takes advantage of the feet that most 
of the fields in the IP. UDP and RTP headers do not change at all during flie RTP session, or 
change by an increment that is generally constant. On this basis, the IP/UDP/RTP header in 
most of the packets is compressed down to two bytes, or four bytes when UDP checksums arc 
included. 

SUMMARY OF THE INVENTION 
It is an object of some aspects of the present invention to provide methods and 
apparatus for multimedia communications over power line communication (PLC) networks. 

It is a forther object of some aspects of the present invention to provide methods and 
apparatus for efficient, reUable Voice over IP (VoIP) communications using PLC networks. 
20 In prefferred embodiments of the present invention, a communications system 

comprises a ptanOity of data transceivers coiq>led to a network of power lines, preferably 
siq)plying mains voltage. Typically, the transceivers include a concentrator, which connects 
the power line network to a data communication network trunk, and power line modems in 
subscriber premises, which link subscriber equipment in the premises to the concentrator via 
25 the power lines. The power line modems preferably include bodi computer data ports, to 
which a user may connect a computer for serial or parallel data transfer, and telephone ports, to 
which the user may connect a conventional telq)hone handset. Tlie concentrator is connected 
via the data conmnmication trunk to a telephony server system, which preferably includes a 
gateway to a public switehed telephone network (PSTN). Users can thus send and receive 
30 telephone calls over the power lines by communicating throu^ the concentrator with the 
telephony server, using either their telephone handsets or telephony appUcations on their 
computers. 
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The transceivers monitor the traffic that they are conveying in cider to detect streams 
of voice or video traffic, preferably by detecting RIP packets. When either the concentrator or 
one of the subscriber modems detects such a stream, it signals the transceiver at the other end 
of the link to estabUsh a RIP connection for carrying the traffic. The connection is assigned a 
5 short (preferably one byte) connection identifier. The connection context, comprising the 
RTP, UDP and IP parameters that do not vary fiom packet to packet in the stream, is stored at 
both ends of the link, indexed by the connection identifier. Subsequently, for the duration of 
the connection, the sending transceiver removes the IP/UDP/RTP packet head^ and, as long 
as the header parameters have not changed, substitutes a brief header containing the 
10 connection identifier and a sequence number for detecting lost packets. PeriodicaUy, the 
receiving transcdver returns an acknowledgment packet to the sender, indicating the sequence 
number of the last packet that was received intact, and informing the sendo- of any lost or 
coinq)ted packets. In this way, the narrow bandwidth of the PLC network is used efficiently, 
by reducing substantially the overhead of voice and video streams. At the same time, the 
reliabiUty of voice and video communications is enhanced by adding an acknowledgment 
mechanism that is absent in the connectionless protocols usually used for i«al-time 
communications. 

There is therefore provided, in accordance with a preferred embodiment of the present 
invention, a method for communication, including; 

estabUshing a data link between first and second transceivers over an electric power 
line; 

receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a connectionless real-time network protocol; 

responsive to a first packet in the sequence, estabhshing a reUable connection channel 
25 for the session over the data link between the first and second tiansceivenj; and 

transmitting the packets in the sequence fiom the first to the second transceiver over 
the reliable connection channel. 

TypicaUy. the packets include header information, and transmitting the packets 
includes compressing the heada- information in the packets transmitted using the channel fiom 
the first to the second transceiver. Preferably, establishing the reliable connection channel 
includes storing context information with respect to the session at the first and second 
transceivers, and compressing the header information includes compressing the header 
information using the stored context mfoimation. Further preferably, storing the context 
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mfimnation includes conveying the contort infennation to the second transcdver along with a 
channel identifier in the fiist packet in the sequence, and compressing the header infonnation 
inchades inserting the channel identifier in the packets in the sequence foUowing the first 
packet as a reference to flie context infonnation. Most preferably, the method includes 
5 reconsliucting the compressed header infbrmation at the second transceiver using the stored 
context information referenced by the channel identifier. Additionally or altematively, 
compressing the header mfoimation inctades detecting changes in tiie header information in 
successive packets in flie sequence, and encoding tiie changes. 

Preferably, the method includes sending an acknowledgment fiom tiie second 
10 transceiver to the first transceiver responsive to at least some of the packets in the sequence 
transmitted by the first transceiver, thereby maintaining tiie reUable connection channel. 
Further preferably, establishing tiie reUable connection channel includes determimng an 
acknowledgment interval that includes a given number of tiie packets, and sending tiie 
acknowledgment includes sending tiie acknowledgment every time tiie given numbo- of 
15 packets has been received at flie second transceiver. Most preferably, transmitting tiie packets 
includes adding an error detection code at tiie first transceiver to one of tiie packets in tiie 
acknowledgment interval, and sending the acknowledgment includes checking flie error 
detection code at the second transceiver, and indicating a result of tiie checking in tiie positive 
or negative acknowledgmCTit returned by the second transceiver. 
20 Additionally or altematively, tiansmitting tiie packets inchides adding a channel 

sequence number to each of tiie packets, and sending tiie acknowledgment includes sending an 
indication fiom tiie second transceiver to tiie first transceiver when flie channel sequence 
number of ttie packets recdved at the second transcdvo: deviates from a consecutive order. 

Furttier additionally or altematively, establishing the reliable connection channel 
25 inchides sending a request Scorn tiie first tianscdiver to the second transcdver to allocate a 
resource for tiie channel, and sending tiie acknowledgment includes indicating to tiie first 
transceiver in a negative acknowledgment fliat tiie second transceiver does not have flie 
resource available to opoi tiie channel. 

In a preferred embodiment, tiie first and second transceivers inchide a subscriber 
30 transceiver in a subscriber prranises and a concentrator, and wherein flie electric power line is a 
part of a mains voltage power line netwoik to which the subscriber transceiver and the 
concentrator are connected. Typically, tiie subscriber transceiver is one of a plurality of such 
transceivers in multiple, respective subscriber premises cormected to tiie power line network, 
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«.d ao concentrator is oonpled to link ae phmlBy of tt» tnn«»vas to a paoke. 
connn»ic«io. ttnnt Rrfc^ty. „^ ^ of fto data p.ck«. includes 

«o«™garea..to.d.uflowtob. conveyed Ween d„s*.cdb.rp^ 3.,.^^ 
via fl,ep«te.«,nn„„nicsaon hunk. Mos.p,efartfy.reo«ving4e,estSn,e data flow 
tr^K*^"™^ ^ a. n..„«k ser^r inchrde, a ....phony gatoway. which 
«coupI»itoapubac.wiW.edW.jhon.n.«,o*(PSTO). fa. tetter prefer, embodinren^ 
a» tolepi».y data inchrde. ,ec«ving data associated with a telephone caU placed 

TLZIT TT — - - power Une netwo* to another 

10 as a ^tua, e^ohang^ so a. to convey the teleph^y data Son, the one of the suhscn^. 
jremses to Hie other without sending the data through the PSIN 

S. another pref«,«, en*odiMent. receiving the sequence „f the data pack«s include. 
"^«-^un.nmBhn««.d«a.pre«erahlyvideodataand/orvoicodata^ Mostp^iy 
cd^ainCndesconpUngatCephonehandsettooneofthet^scTers 

rr*rr" " " '^-^ °- of an; .he 

telephone handset Altenaatively, receiving the voice data inch^ eouphng . pe^ 
^ to one Of me transceivers. s,»i conveying 4. d«. p«ieta heftveen a,, on. of *e 
tansccivers and a voice appUcation on the personal computer. 

:0 ««»rtance with a Real-time lianster Protocol CRTP). J>«Muim 

''■•"i'^'^-' provided, in «»o.dance with a p«fe.™i.mbodin,ent of are present 
Zo r rr:":"""" '^'^ > t^nscdve,. which l, configured to 

«tahh.h .data hnk With -^cnddsta^er over an eleCHopoweran. such .Tin 
^»™.g a scuence of data packeta ^ over the data lint the se,ule 

be,o^^toase,s.onofaconnection,e.srea...in.ene.wo*p,otocol.^ 

l^tZr^' - ^^uence. to estah^sh a rehahie conncc«on 

0^1 the sesston over «,e data hnk with the second transceiver and to transnn. the 
packets u. the sequence to the second tr«,sceiver over the reliable connec«on channel 

muh.W *• -'"^^ -l-tinie 

r <^ «.d the flrst h^-sceiver includes a telephone adapter. 

tC^hone handset Altomatively or «Mitional,y. .he iirst transceiver includes a computer 
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commamcation port, which is configured to exchange the voice data in the fonn of voice 
packets to and firom a voice application on the personal compute. 

Preferably, ttie first transceiver includes one of a subscriber transceiver in a subscriber 
premises, and a concmtrator, and flie electric power line is a part of a mains voltage power line 
5 network to which the subscriber transceiver and the concentrator are connected 

There is additionally provided, in accordance with a preferred embodiment of the 
present inveation, communication apparatus, including: 

a subscriber transceiver, for d^loyment in a subscriber premises, the subscriber 
transceiver being adapted to be coupled to an electric power line belonging to a mains voltage 
1 0 power line network; and 

a concentrator, coiq)led to the power line network so as to convey data between the 
subscriber transceiver and a packet communication trunk, the subscriber transceiver and the 
concentrator being configured to establish a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
15 the sequence belonging to a session of a connectionless real-time network protocol, the 
subscriber transceive: and the concentrator are adapted, responsive to a first packet in the 
sequence, to estabUsh a reliable connection channel for flie session over flie data link and to 
transmit ttie packets in the sequence Scorn one to another over the reliable connection channel. 
The present invention will be more fully understood fiom the following detailed 
20 description of the preferred embodiments thereof taken together with the drawings in which: 

BRIEF DESCRIFnON OF THE DRAWINGS 

Fig. 1 is a block diagram that schematically illustrates a system for power line 
communications (PLC), in accordance with a preferred embodiment of the present mvention; 

Fig. 2 is a block diagram that schematically shows details of a power line data 
25 transceiver, in accordance with a preferred embodiment of the present invention; 

Fig. 3 is a block diagram that schematically shows communication protocols used to 
carry voice traffic in a PLC system, in accordance with a preferred embodiment of the present 
invention; 

Fig. 4 is a table that schematically illustrates a packet header used in real-time network 
30 communications; 

Fig. 5 is a flow chart that schematically illustrates a method for compressing packet 
headOT in a PLC system, in accordance with a preferred embodiment of the present invention; 
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Kg. 6 is . flow chat Ih3. schomjicdly ffluame, . m«hod for deoon.pr««ng 
invention; 

Hg.. 7A.7D « fl,« j,^^ ^ ^ ^ 

5 <»"'«««<»andde<»mpre.n<mm«tho<bofKgs.5md6;and 

Hg. 8 is . a™ cb« schanuicauyiltetete drtailsof a mettod forpadceel»sder 
conipresa.™, in «»,rtsnoe ^th . prefe™, embodiment of the present invention. 

DETAILEB DBSCRlmON OP PREIERRBD EMBODIMENra 

I%li..bI«*di.gramtotsohemadcaUyiBns<ra.«,acomn.nnloa.i«.s,st«n20 in 
'^"™*«P»'-'«>*o^entor,bepres««inven.i„n S^«n .0 is b^ sr,™;,: 
P^ ^ oommnmo-ion (PU, network 22. wMob nses . power iin, 24 to o.„y digit,. 

of dte present uivention is not limited to a speoiflo levd or txpe of lino votoge 

• nr.: ^•'^-"«™"^«'»-iver34.w..iobaC.,J 
"f"^-P--'i"«^^-d™bscnT«e^m,n..snch„.p^^^^3^^^ 
^ a telephone ^sceiver 34 is desonb«, in g,«,er detaU below „i«. ^ 
Oneormo.mas.ertr,nsc.iv«,..^,„i.^e,.^^^^^^^ 
toapaclcetnetwoAtrank40. The Inuik typically ha. a. fc™„f. 

maintained by an eleetriertHi^, ''''™^'^'^*™<'f'w.deareanetwodc(WAN) 
amed by an deetrn, ntd.^ comp»>y ,„ c«,y connnunications brtw«„ (he concentrators 

^'^'low-v.l.ag.s.gment.ofthepow.r.ys.em.snch.sonlinez* 

' inchJ^w"'^'"^°^''''°"™°^°''^''*»"~-«°"-^^^ 
^J^h-^netand.pnbBcswitohedtelephone^^^^ ^ • 

enaoies subscnbere in premises 26 28 f« j . 

* " " P^*^ '^^^vs telephone caUs over PLP 

*e 1^ Of pac^ voice and signahng data, topically using i,temet P JoLl (IP) 
-»™c»^onbothpoweriinea4«^t,nnk40. Gateway 42 internes with PSIK^ 

ZTTf ^ - Vice versa, as is ...wn in r« 

Srgnahng for call, on PU: network 22 is „,med to a gateiceeper 4«, which is a served 

rwponsibie for tasks snch «, assigning an n> add«s to lb. ' ■» « «»™ 

Bimig w u- aooiess to the calhng party, veri^ing that the 
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called party is available and tbst the call is aufhorized, and monitoring calls for billing 
purposes. A network management system (not shown) coupled to trunk 40 is responsible for 
allocating bandwidth to calls, depending on the load on PLC network 22. Preferably, the 
level of compression of the audio data carried on network 22 and trunk 40 is variable, under 
5 control of the network management system, in response to variations in the network load. 

As an addition or alternative to gateway 42, telephone calls to and from transceivers 34 
may be handled through a virtual private branch exchange (PBX) 48, coi^)led to trunk 40. 
PBX 48 is preferably implemented as a special telephony ^pUcation r unning on a 
general-purpose network server. In addition to interfacing with PSTN 44, PBX 48 acts as a 

10 switch in a private telephone network serving customers of the electrical utility company who 
use PLC n^ork 22 for their telephone calls. PBX 48 routes local telephone calls between 
such customers througji trunk 40 and the subscribers* local power lines 24, wifliout using 
PSTN 44. This feature of the PBX allows the utihty company to offer local tel^hone service 
at reduced rates, relative to the PSTN. Outgoing and incoming calls involving telephone 

15 subscribers outside the local PLC network are routed by PBX 48 to and from PSTN 44, in a 
manner similar to VoIP gateway 42. 

Voice telephony is thus carried over PLC network 22 in much the same way as other 
types of packet data, but wifli a few itaportiaak differences. One difference is that the telephony 
packets are preferably assigned a high level of priority, relative to other types of traffic, so as 

20 to provide adequate quality of service (QoS) for real-time voice. In addition, the voice packet 
headers are compressed to conserve bandwidth on the PLC network, as described in detail 
hereinbelow. Other real-time multimedia trafiSc, such as real-time video, whidh is typically 
fed to PLC network 22 from the Intemet and from entertainment networks, is preferably 
treated in a similar fashion to voice, with high priority and header compression. Therefore, 

25 although preferred embodiments are described herein primarily with reference to telephony 
applications, it will be understood that the principles of the present invention are similariy 
applicable to other types of real-time data trafBc. 

Fig. 2 is a block diagram that schematically shows details of one of subscriber premises 
transceivers 34, in accordance with a preferred embodiment of the present invention. The 

30 design and operation of transceiver 34 are described in greater detail in PCT Patent 
Application PCT/ILOl/00745, filed August 12, 2001, which is assigned to the assignee of the 
present patent application and whose disclosure is incorporated herein by reference. 
Transceiver 34 comprises a multi-function modem unit 50, which acts as an inter&ce between 
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P»w« line 24 aad low-voltage date iAn,^™ Un... Module, of nnh 50 a. 
da»^i.v«sion oinndtty. «cep«^ ^ ^ ^ _ ^ 

«^hoi.e ooBvertag the data to dgnls «^«n,te ^ia, the pow« line, as weU as 
P^fozBung a» „v«« opomloa Certata .nod.,e. auo act a. a d«. oomm™ioa««. oootoUcr 
52. and as levetsettiiw oiicnitiy Ite tamanissioa of Ihe data. 

Tftan,c^34i,p„ft,rt,lyeo«pledtoline24by.nindnshy.^ 

llTlrtT ^ « « • *n^>« converts be^een sen,, data 

jab of a data in* nm, 58 and power Hn. signals of power line 24. A logic „od.le 60 
^J-f. wi* a 0^ p^ ^ used .o opera, and 

conso, o,^ nK-dnle. con^sed in ft. .^er. 1, addition .o ac«ng as 1 overall 

rtTTr^''- '=^«''>-"^«» -aureceivcd byand nansn^ to 

^ mod.^» of *e ,.ansc.iv.r. as wen as to control routing of connrrunication. b«w.en 
^-v.r34and«teetan^ofPU>ne.„o..2Z CPU 62 preferably op^aie, using a 
voMe n»n«y 66 such as a random access m«„ory (RAM), contaiuing a rowing toble 68 
^. «».vol«ile n-enrory 70. sue. as a flash n^ry. M«n«,es 66 and 70 are Lupled to 
CTO62liyanuitemalbusline64. 

CPU 62 oonnnunicatos witt, fte otter u,«iules of *.n«»iv., 32 via logic 60 
"tech acs as a multiplexer, tiansferring da- to and iron, subscriber e,.ipn.«. intoftce' 
modules 72. 78. 80. 82 and 86, Whose functions are deairib«i bd„w: 

• CODEC modulo 82. preferably an indnstiy^andard OODEQ trm^ and 
reccves standard ,eleph«» signals via an industiy-sUmdard connector 84 to and item 
..cphono 38. Tt. CODEC carver,. a.e analog tol.phone signal to a sni«,le digiul 

f^2a^U,ea323fonna.pr„mnlgatodbyti,e,ntorna«c™lTele»^ 
Umon crru). and vice versa, in a fuBAipleK manner. 

. =CP'nodul.80c™mmnticatoawi*pen^computor36viaanindustiy.stente^ 
parallel port of the computer. 

• RS-232 module 86 provid« industiy-stadard serial communication, via a 
connector 128. 

. M»me. module 72 provides paclce. dato commumcations. using a standard 

C T« ^ " ^"-^ 36 may cornet to module 

72 either directly via connector 74 or via a LAN 76. 
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• Alternatively or additionally, Universal Sraal Bus (USB) module 78, which is 
preferably coupled directly to CPU 62, communicates with aUSB host via connector 
74. 

Fig. 3 is a block diagram that schematically illustrates protocols used in voice 

5 communications over PLC netwoilc 22, in accordance with a preferred embodiment of the 
present invention. The communications are shown, by way of example, as taking place 
between eiflier personal computer 36 or telephone 38 and VoIP gateway 42, via subscriber 
PLC transceiver 34 and concentrator 32. The communications are generated at tiie subscriber 
end as a RTP packet stream, which is preferably produced by a suitable IP tel^hony 

10 application running on computer 36. Alternatively, the subscriber may use telephone 38 to 
generate audio and signaling. In this case, CODEC module 82 converts the telephone output 
to standard digital form, and data Unk unit 58 generates the RTP header data, as well as 
processing the RTP packets retumed from the party at the other end of the telq)hone call. 

Thus, a subscriber-end protocol stack 100 shown in Fig. 3 comprises RTP, UDP and IP 

15 layers on the subscriber side, naming over local media access control (MAC) and physical 
layer commimications provide by the appropriate subscriber equipment mterfaces, such as 
Ethernet interface module 72. When CPU 62 generates or detects an outgoing RTPAJDP/IP 
packet stream, it prefCTably establishes a point-to-point connection between transceiver 34 and 
concentrator 32 for the purpose of carrying the stream, and tiien compresses Ihe packet headers 

20 in the RTP/UDP/IP session, as described in detail hereinbelow. Concentrator 32 preferably 
functions in like manner with respect to incoming packet streams from trunk 40. The RTP, 
UDP and IP layers are then carried on power line 24 between subscriber transceiver 34 and 
concentrator 32 by a special, compressed telephony layer, over the PLC MAC and physical 
layers generated by data link unit 58 and PHY module 54. The MAC layer protocol is 

25 described in detail in the above-mentioned PCT patent application. 

hi a concentrator stack 102, running on concentrator 32, the compressed telq)hony 
layer for outgoing calls is decompressed to recover the original RTP, UDP and IP headers. 
Conversely, in:coming RTPAJDP/IP headers are conq)ressed for transmission to transceiv^ 34. 
The RTPAJDP/IP voice packets may also be carried over packet trunk 40 in compressed form, 

30 and decompressed at gateway 42 or at another point along the way. The MAC and PHY layers 
on the trunk side of concentrator 32 are typically those of a standard data link protocol used on 
the packet network to \^ch trunk 40 belongs, preferably an Ethernet protocol. 
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Stored in a pool in memory by both tiie transceiver and the concentrator (for scample, in 
memory 66, Fig. 2). The context entries are preferably stored in the memory as a linked Ust, 
referenced by a hashing function based on a certain nvraibCT of the least significant bits (LSB) 
of the RTP SaiC and the IP destination address for the respective sessions. Table I below 
shows a preferred structure for the memory pool context entries. 



TABLE I - SESSION CONTEXT PARAMETERS 



Category 


JP1CJIC& 


Size 
(bits) 




r^ftnfevt TO ^channel number) 


8 


Counters 




8 






16 


Seq 




4 


State 


Onannei state ^acuve, inacave^ penuiiig — see ucxuwy 


4 


Timejtag 


Last i^xlate to tms cnsmici ^ cnannei is cxearoa axicar 
tuneout occurs wiui no upaaie 




RTP 


Pbit 


1 
1 




X bit 


1 
1 




cc 


*T 




Mbit 


1 

1 




Pavload tvoe 


7 




Previous sequence niunber 


16 




Previous timestamp 


32 




SSRC 


32 




CSRC (pointer to list) 


16 


UDP 


Source port 


16 




Destination port 


16 


IP 


IHL 


4 




Type of service 


8 




Previous ID 


16 




Flags 


3 
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Last seq number acknowledged 
Last CRC sent (on seq number) 
Debug state 
Link to next entry or end of list 



15 



20 



pa^C a. 34. for ^ ^ ^ ^ 

headwcon^resnoii, >t apacket semliiig stop 124. 

Wh« unit 58 d««ri„«, th., i, ^ ^ 

If such a ^ ^ ^ ^ J 

v->d octe. co». Oess ^ p,,,e. ^ ^„ ^ „^ 
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conditions are not satisfied, a channel should not be opened, and the packet should instead be 
sent without compression at step 124. 

When a new channel is available, data link unit 58 creates the channel in its memory 
pool, and assigns it a context ID (OD), at a channel creation step 130. The memory pool now 
5 includes the fiill packet context, as specified in Table I above. To notify concentrator 32 that a 
new channel has been opened, unit 58 replaces the UDP length field in the UDP header (Fig- 
4) with a FULLHEADER identifier field, at a header replacement step 132. The 
FULLjaEADER identifier, shown below in Fig. 7A, includes the assigned CID and the 
starting link sequence number (Seq). The modified pactet is then sent on to concentrator 32, 
10 at a new packet transmission step 134. Upon reading the packet header with the 
FUIX_HEADER idratifier, the concentrator opens the channel in its own memory pool, using 
the CID, Seq and context information in the packet header, and is now ready to receive 
compressed packets. 

When at step 126, data link unit 58 determines that the current RTF packet belongs to 

15 an existing session already opened in the memory pool, it iq>dates the corresponding chaimel 
timejag field, at a timCT update step 136. It then checks the channel state (see Table J) to 
detemiine whether or not the channel is active, at an activity checking step 138. A channel is 
deemed inactive when the concentrator has signaled, using the acknowledgment mechanism 
described below, that it has received packets with errors or that packets have been lost on this 

20 channel, hi such as case, the original packet is sent without header compression to 
concentrator 124. A channel may be deemed pending if, upon an attempt by data link umt 58 
to create the channel, concentrator 32 responds that its memory pool is full. Packets are 
likewise sent over pending chaimels wifliout header compression. Such channels are 
ultimately erased from the memory pool of data link unit 58 by an aging mechanism if 

25 resources are not freed so that the pending chaimels can become active. 

When the RTF packet is found at step 138 to belong to an active chaimel, data link unit 
58 performs validity checks to ascertain that the channel is still valid, at a validity checking 
step 140. The packet header is then compressed, and the compressed packet is sent to 
concentrator 32, at a compressed transmission stqp 142. Details of steps 140 and 142 are 

30 described below with reference to Fig. 8. 

Fig. 6 is a flow chart that schematically illustrates processing of compressed packets 
received by concentrator 32 from transceiver 34, in accordance with a preferred embodiment 
of the present invention. (As in the case of the mefliod of Fig. 5, this same method is carried 
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Ba«ortl™d,rn6(Fig.4)tt«„mand.ted»ystarfrtp„,tocote 
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IS. fi. th„ case, too, the concentrator sends a CONTEXT.STAIE packet back to 
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transceiver 34, indicatmg that it is out of fiee channels, at a reply step 162. Despite the 
negative response, however, the concentrator is still able to reconstruct the original, standard 
RTP/UDP/IP header by recalculating the UDP length, at a length recalculation step 164, and 
reinserting the length into the UDP header of the packet in place of the FULL.HEADER field 
5 that was substituted by transceiver 34. The concentrator tiien sends the reconstracted packet 
out over IP trunk 40. 

Returning to step 1 56, if concentrator 32 finds ttiat tite CID in the padcet header exists 
in its own memory pool, it updates the timejtag in the corresponding channel context, at a 
timer updating step 170. It checks the source MAC address of the packet against the context, 

10 to ensure that the packet is valid, at a validity checking step 172. It also checks the sequence 
number (Seq) of the packet to ensure that it is exactly one greater flian the preceding packet 
received on fliis channel. If so, concentrator 32 can proceed to decompress the padcet and 
reconstract the RTP/UDP/IP header, at a deconq>ression step 174. Details of the 
decompression process are described hereinbelow. If a packet is missed, the channel becomes 

1 5 inactive, and the packet cannot be decompressed or sent 

In order to maintain synchronization between the sender and receiver of compressed 
packets, the receiver is required to acknowledge the compressed packets it has received, at an 
ACK requirement step 176. For this purpose, a time window, T, is defined at both the sending 
and receiving ends, such that every T compressed packets an acknowledgment protocol is 

20 carried out The sender preferably saves the sequence number and spends a cyclic 
redundancy code (CRC) value to the packet whose acknowledgment is required. The receiver 
recomputes the CRC and compares it to the appended value. If the CRC values match, the 
receiver returns an ACK packet (i.e., a CONTEXT_STATE packet) with the sequence number 
to flie sender, at an acknowledgment step 178. If there is a mismatch of the CRC values, the 

25 receiver returns a CONTEXT_STATB NACK packet. In an optional debugging mode, the 
receiver may check the CRC of every packet, and send a NACK response to the sender for any 
packet in which the CRC check fails. When the sender receives the ACK response firom the 
receiver, it checks the sequence number and CRC value against the values it has saved, and 
clears flie values if they matoh. If the sender does not receive the proper ACK, it sends a 

30 FULL^HEADER packet in order to refi-esh the channel context. 

When concentrator 32 determines at step 172 that a packet has been lost, it must send a 
NACK to transceiver 34, in the form of a CONTEXT_STATE packet. Ihe NACK packet 
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reports the sequence number of the last packet received and requests tnu^anission of a 
FULLJBBADER packet to update the channel context 

Figs. 7A-7D are tables that scheniaticaUy iUustrates the types of packets sent between 
transceiver 34 and concentrator 32 in carrying out ttxe compression and decompression 
5 protocols of Figs. 5 and 6. The packet types generaUy foUow flxe definitions in the 
abov^mentioned RFC 2508. with changes ^prepriate to the specific constraints and 
requmsments of PLC network 22. Fig. 7A shows a FULL.HBADBR field 200 that is inserted 
mplaoe of the length field in the UDP header (Pig. 4) of a fidl RTP/UDP/IP packet header 
Reld 200 includes a version number 202 (for example, "01"). context ID (CID) 204 and a 
10 cunent sequence number (Seq) 206. An optional "IT bit invokes the above-mentioned debug 
mode, in which a CRC is added by the sender to each of the compressed packets and is 
checked by the receiver. 

Pig. 7B shows a COMPRESSED.UDP packet 210. which is sent by the transmitter 
^ the P. X or PT field in flie RTP header has changed. When such a change occurs 
additional information must be conveyed to the receiver in order to update the channel context' 
and this infonnation is conveyed by the COMPEESSBD_UDP packet. The packet header 
mcludes OD 204 and Seq 206. as weU as an «T' flag 212. Hus flag is set if the IP version 4 
(IPv4) ID has changed by an amount other than one from the precedmg packet to this one. If 
'T' IS set. packet 210 includes a AIP field 214 that gives the actual ID change. Preferably, the 
change inlD is encoded using a Huffinan encoding scheme, as is kno^ in Ae art. so that 
common values of the ID change (tjpicaily in the range 0:127) are encoded as a sin^e byte 
while less common values take two or three bytes. A scheme of this sort is suggested in RFC 
2508. No further encoding of the IP or UDP header is required. (If it were a 
FULL.HEADER packet would be sent) The packet next mcludes UDP data 216 which 
comprises the fuU RTF header and payload. fi,llowed by an optional checksum218 

Fig. 7C shows a COMPRESSED.RTP packet 220. which is sent when the changes in 
^ RIP/UDP/IP header are minimal. Following CID 204. the packet inchides compression 
flags 222, with the following meanings: 

. "M"indicatesthatthe«]Vr'bitintheRTPheaderhaschanged. 
. «S" mdicates that the RTF sequence number has changed by an amount different 
from the usual sequence increment Ih this case, a ARTP sequence field 224 contains 
the actual change in the sequence number, preferably using a Huffinan encoding 
scheme as described above. 
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• 'T* indicates the RTP timestamp has changed by an amount different ftom the 
usual time increment In this case, a ARTP timestamp field 226 contains the actual 
change in the timestamp, preferably usmg a Huffinan encoding schone as described 
above. 

5 • 'T' indicates that flie IPv4 ID has changed by an amount different ficom one, with its 

actual change given by field 214. 

• When all of M, S, T and I are set, and a CC field 223 is not equal to zero, a CSRC 
list 228 is included in packet 220, with a length given by flie value of CC. In this case, 
file values M»S»TH[»1 are artificial, to signal that fiie packet includes the CSRC list, 

10 and the roles of flags M, S, T and I are respectively assumed by flags M*, S', T' and 1\ 

If the bit is set in the RTP header, the header extension is contained in a RTP header 
extension field 230. The remainder of the packet contains RTP data 232, followed by optional 
padding 234 (if the 'T** bit is set) and checksum 218. 

Fig. 7D shows a CONTEXT^STATB packet 240, used for the ACK and NACK 

15 fimctions described above. An 'TP" bit 242 is set by the receiver to indicate that its memory 
pool is jfull, so that a new chamiel that the transmitter has asked to open must remain in the 
pending state. An "A" bit 244 is set to indicate a positive acknowledgment (ACK), and is 
reset for NACK. Seq field 206 indicates the sequence number of the last packet that the 
receiver was able to read on this channel. The use of the CONTEXT^STATB packet in this 

20 manner (which differs fcom that proposed in RFC 2508), with a predefined window for 
positive ACK req)onse by the receiver, turns the unidirectional, connectionless RTP/UDP 
packet stream into a fiall-duplex, connection-oriented, protocol within PLC network 22, while 
at the same time saving substantial bandwidth. Both of these features are particularly 
important when working ovct power line 24, with its high noise level and low bandwidth. 

25 Fig. 8 is a flow chart that schematically illustrates the use of packet formats 200, 210 

and 220 in sending compressed RTP packets over PLC network 22, in accordance with a 

preferred embodiment of the present inventioiL The steps of the method shown in Fig. 8 

* 

correspond roug^y to validity checking step 140 and compressed transmission step 142 in Fig. 
5, after transceiver 34 has ascertained that the RTP packet in question belongs to an active 
30 channel m its memory pool. 

The method of Fig. 8 is initiated when transceiver 32 receives a RTP packet to 
compress on a valid, active channel, at a packet reception step 250. The transceiver first 
checks fields that are supposed to remain constant over an entire RTP session: the IP source 
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ta« obliged in ft. <™,« paote, .^v, to to ctaand o<mt« in ft. 

cun»t ch..„d i. =»,d. at ™ «^ 254. A w cham-d b. to to 

wim the new parameters. 

5 of ft, „tt^n,p^^,^j^^^^ ^^ 

an n. choking s^p 256. Ti^ fl.,a. „. ^ ^ ^ 

«cq«.on of ft. n. ID &H. ^ch i. incremem«i fiom pacl« to packet If any of ft, 
P«m.^ cl^ Oft., ftan ft. ID ^ ^ ^ 

,0 '^-^^'»*'^-'*"'™»'«i-«.p258. »apaok«r.ft.ab..ft.^„f 

If ft.pa<*«pa«« «ep 256 sacc«slUIy, ft. transcdver to **™in, wi»ft.r 

a-fl- of *. P. X or PT of ft. rtp hav. chang.d relaHv. to ft. *„m.I co,««^ a. 
a RIP pan«n««. checking s.q, 260. As noted abov.. if a.,, of ft«, fl.M. tav. oh«^ 
«»-P-««'W>Ppacket220is^t.atacon„«a«.iroPs««ng«,2«2. Iftb.n.ID 
15 '^«'"-^changcd,ft.pack«»inal«,inctad.ft.appT„priM.4nV4IDfldd214 

''"-'-f'h-'Rn'fleldahav.changed.ft.tau^dv.rcheck.ft.oft^Rwh.^b, 

fields, as wdl as ft. n. n> fi.Id. in o,d« to ^cod. «^ in ft, fl.ua, a. an 

^ ^ 264. Ilese change, inch«fc change, in ft, fl.h.s ft^nselvc. .«„ fte M and 
CSRC fields, as well as change, in ft. inc^ of «« ,„„„„„^^ ^ ^ 

n> fields, ^changes ^c^,,,^^ above, and ft. con«ponding 

TlZI^'' ^''^ ^ - ». -oo^y. a. a flag taiaing 266. Mo« ofl «n,e 
fi^d. 214, 224. 226 and 22, a:. «np.,. ^ f^ 222 and field 223 are ^. Ihe packet 
cannowbesenttotheconceaBtratQr32. 

Ih «der to monitor dccooipression processing activities, concenti^or 32 prefeiably 
25 maintains tiie following counters: 
• Global counters - 

• Total RTP packets reconstructed. 

• Total syncluoni2ing(FULL_HEADER) packets received. 

• Total semi-compressed packets received (COMPRESSED_UDP). 

• Total fuUy-compressed packets received (COMPRESSED_RTP). 

. Totalsynchronizingpacketssent(CONTEXT_STATBwitliFbitoflD. 

• Total rqect packets sent (COOTKCr.STATE with F bit on). 

• Total active chaimels. 
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• Total inactive channels. 

« Number of available channels. 
• Per-channel coiinters — 

• Total compressed packets received. 

5 • Total synchronizing packets sent (CONTBXT_STATEwiaF bit off). 

Reconstruction of the conqwessed packets, at decompression step 174 (Fig. 6) is a 
minor image process to fbat shown in Fig. 8. When the compressed packet is a 
COMPRESSED_UDP packet, concentrator 32 ^crates tide decompressed RTP packet to 
send over trunk 40 usmg the RTP channel infbnnation in UDP data 216. along with the 

10 remaining context data for the channel that is stored in the memory pooL The concentrator 
increments the IP ID by 1 if 1=0, or by the number indicated in field 214 of the packet if 1=1. 

For a COMPRESSBD_RTP packet, if M=S=^I=1. and CC is non-zero, the CC field 
in the channel context is updated with the value in field 223 of packet 220, and the CSRC list 
in the context is replaced with the contents of field 228 in the packet. This new information is 

15 used in all reconstructed packets, beginning with the current one. Dependmg on the values of 
M, S, T and I (or of M', S*, T' and T, if M=S='P=I=1), the remaining variable fields of the 
RTP packet are reconstructed, using constant increments or the special mcrements given m 
fields 214, 224 and 226. Header extension 230 and padding 234 are optionaUy added to the 
packet, the UDP length is recalculated, and the packet is sent out on trunk 40 as a standard 

20 RTPAJDP/IP packet 

As noted above, althou^ the processes of chamiel creation and of compression and 
decompression of RTP packets are described with respect to packets transmitted from 
subscriber equipment, via transceiver 34, to concentrator 32 over power line 24, similar 
methods are used to create channels and to compress and decompress packets received by 

25 concentrator 32 from packet trunk 40 for transmission over the power Ime to transceiver 34. 
Furthermore, although for the sake of clarity, these processes are illustrated with reference to a 
single connection m the very simple PLC networic 22 shown m Fig. 1, it will be understood 
that the mefliods exemplified by the preferred embodiments described hstern may equally be 
appUed m more conq)lex PLC network topologies, with multiple RTP sessions going on 

30 simultaneously. 

More generally speakinfe while RTP/UDP/IP provides particularly fertile ground for 
creating connection-oriented sessions and performing header compression in a PLC network, 
the principles of the present invention m^ also be ^plied to other connectionless protocols, 

20 



Page 23 of 3 



10 



wo 02/25822 

PCT/ILOl/00872 

particularly real-time protocols, that are used in the PLC network environment Furthermore, 
although preferred embodiments are described herein ^th specific reference to PLC networte' 
the princqjles of the present irivention may also be applied, mutatis mutandis, to encapsulation 
and compression of packets transmitted over wirelme and wireless networks of other types, 
paiticularlynetworics that, like PLC networks, have highnoise and enorrates. 

It wiU thus be appreciated that the preferred embodiments described above are cited by 
way of example, and that the present imrention is not limited to what has been particularly 
shown and described hereinabove. Rather, the scope of the present invention includes both 
combinations and subcombinations of the various features described hereinabove, as weU as 
variations and modifications thereof which would occur to persons skiUed in the art upon 
reading the foregoing description and which are not disclosed in the prior art 
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CLAIMS 

1 • A method for communication, comprising: 

establishing a data link between first and second transceivers over an electric power 

line; 

5 receiving a sequence of data packets for transmission over the data link, the sequence 

belonging to a session of a connectionless real-time networic protocol; 

responsive to a first packet in the sequence, establishing a reliable connection channel 
for the session over the data link between the first and second transceivers; and 

transmitting the packets in the sequence fix)m the first to the second transceiver over 
1 0 the reliable connection channel. 

2. A method according to claim 1, wherein the packets comprise header information, and 
wherein transmitting the packets comprises compressing the header information in the packets 
transmitted using the chaimel fix>m the first to the second transceiver. 

3. A method according to claim 2, wherein establishing the reliable connection channel 
15 comprises storing context information with respect to ttie session at the first and second 

transceivers, and wherein conipressing the header information comprises conq>ressing the 
header information using the stored context information* 

4. A method according to claim 3, wherein storing the context information comprises 
conveying the context information to the second transceiver along with a channel identifier in 

20 the first packet in the sequence, and \;^erein compressing the header information comprises 
inserting the channel identifier in the packets in the sequence following the first packet as a 
reference to the context information. 

5. A method according to claim 4, and conoprising reconstructing the compressed header 
information at the second transceiver using the stored context information referenced by the 

25 channel identifier. 

6. A method according to claim 2, wherein coir5)ressing the header information comprises 
detecting changes in the header information in successive packets in the sequence, and 
encoding the changes. 

7. A method according to clmm 1, and comprising sending an acknowledgment firom the 
30 second transceiver to the first transceiver responsive to at least some of the packets in the 
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sequence trammitted by the fcst transceiver, th«eby maintaining the reliable connection 
channeL 

8. A mefliod according to claim 7. wherein establishing the reUable comiection channel 
comprises determining an acknowledgment mterval that comprises a given number of the 

5 packets, and wherein sending the acknowledgment comprises sending the acknowledgment 
every fame the given number of packets has been received at the second transceiver. 

9. A method according to claim 8, wherein transmitting the packets comprises ad^ 
enor detection code at the first transceiver to one of the packets in the acknowledgment 
interval, and ..i^erein sending the acknowledgment comprises checking fte error detection 

10 code at the second transceiver, and indicating a result of the checking in the acknowledgment 

10. A method according to claim 7. wherein transmitting the packets comprises adding a 
chamiel sequence number to each of fire packets, and wherein sending the acknowledgment 
comprises sending an mdication fiom the second transceiver to the first transceiver when the 

<^J^l«eq««nce number of the packets received at the second transceiver deviated 
1 5 consecutive order. 

11. A method according to claim 7. wherein establishing fire reKable comiection chamiel 
comprises sending a request fiom the first transceiver to the second trover to allocate a 
resource for the ch^el. and wherein sending the acknowledgment comprises indicating to the 

fi-**--<'«ver whether or not the second transceiver has the resource a^^^^ 
20 cnanneL 

12. A mettod accordn* to a-g, of data l-1 1. whei^rn ae Bm and ^eco-ri fran^xjven, 
«»pri». a s»tecribertra„»,i«ri„ . sabs«ibe, premises ami a conoentator. and wl«rein a. 
electee I»w.r line is a part of a mains voltage power line netwo* « ft, ^bsoriber 

•MWMver and the concentrator are connected. 

25 13. A method according to claim 12, wher^ the snbscriber transceiver is one of aptaality 
of such t^nsceiven, in muMpIe, respective s^scriber premise, competed to the power line 
network, and wherein a>e concentrator is coupled to link the plma% of the ,r,nsc^y„ to a 
packet communication trunk. 



30 



14. A method according to claim 13. wherein receiving the sequence of the data packets 
compns^ receiving a real-time data flow to be conveyed between the subscriber premises and 
a network server via the packet communication trunk. 
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15, A meOiod according to claim 14, wherein receiving the real-time data flow con5)rises 
receiving telephony data, and wherein the networic server coii5)rises a telephony gateway, 
which is coupled to a public switched telephone network (PSTN). 

16. A metiiod according to claim 15, wherein receiving tiie telephony data comprises 
5 receiving data associated witti a telephone call placed from one of the multiple subscriber 

premises connected to the power line network to another of the multiple subscriber premises, 
and wherein the telephony gateway is further configured to serve as a virtual exchange, so as to 
convey the telephony data from the one of the subscriber premises to the other without sending 
the data through the PSTN. 
10 17. A method according to any of claims 1-1 1, wherein receiving the sequence of the data 
packets comprises receiving real-time multimedia data. 

18. A mefliod according to claim 17, wherein receiving the multimedia data comprises 
receiving video data- 
IP. A method according to claim 17, wherein receiving the multimedia data comprises 
1 5 receiving voice data. 

20. A method according to claim 19, wherein receiving the voice data comprises coupling 
a telephone handset to one of the transceivers, and conveying the voice data as an analog audio 
signal between the one of the transceivers and the telephone handset 

21. A method according to claim 19, wherein receiving the voice data comprises coupling 
20 a personal computer to one of the transceivers, and conveying the data packets between the one 

of the transceivers and a voice application on the personal computer. 

22. A method according to any of claims 1-11, wherein recdving the sequence of die data 
packets comprises receiving the packets in accordance with a Real-time Transfer Protocol 
(RTP). 

25 23. Communication apparatus, comprising a first data transceiver, which is configured to 
establish a data link with a second data transceiver over an electric power line, such that upon 
receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a connectionless real-time network protocol, the first data transceiver 
is adapted, responsive to a first packet in the sequence, to establish a reliable connection 

30 channel for the session over the data link with the second transceiver and to transmit the 

packets in the sequence to the second transceiver over the reliable connection dbannel. 

24 
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24. Apparatus according to claim 23. wherdn the packets comprise header infonnation. 
and wherein the first data transceiver is adapted to compress the header information in the 
packets for transmission using the channel. 



25. 



26 

10 



30 



Apparatus according to claim 24, wherein to establish the reUable connection channel 
contort information with respect to the session is stored at the first and second transceivers, 
and wherein the first data transceiver is adapted to congress the header infomiation using the 
stored context information. 

26. Apparatus according to claim 25. wherein the first transceiver is adapted to convey the 
context information to the second transceiver along with a channel identifier in the first packet 
in the sequence, and to insert the channel identifier in the packets in the sequence foUowing 
the first packet as a reference to die context information. 

27. Apparatus according to claim 26. wherein the compressed header information is 
reconstructed at the second transceiver using the stored context information referenced by the 
channel identifier. 

15 28. Apparatus according to claim 24. wherein the first transceiver is ad^ted to compress 
the header information by detecting changes in the header information in successive packets in 
the sequence, and encoding the dianges. 

29. Apparatus according to claim 23, wherein the first transceiver is adapted, after 
establishing the reliable comiection channel, to receive an acknowledgment fiom the second 
transceiver responsive to at least some of the packets in the sequence transmitted by the first 
transceiver, thereby maintaining the reliable connection channel. 

30. ^paratus according to claim 29. wherein the first transceiver is adq,ted to instruct the 
second transceiver to send the acknowledgment every time a given number of packets making 
up a predetemuned acknowledgment interval has been received at the second transceiver. 

31. Apparatus according to claim 30. wherein the first transceiver is adapted to add an 
error detection code to one of the packets in the actoowledgment interval, and to receive fiom 
the second transceiver in the acknowledgment a result of checking the error detection code. 

32. Apparatus according to claim 29, wherein the first transceiver is adapted to add a 
channel sequence number to each of die packets, and to receive an indication in the 
acknowledgment from the second transceiver when the chamiel sequence nmnber of the 
packets received at die second transceiver deviates from a consecutive order. 
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33. Apparatus accoiding to claim 29, wherein the first transceiver is adapted to send a 
request to the second transceiver to aUocate a resource for the reUable connection channel, and 
to receive the acknowledgment indicating whether or not the second transceiver has the 
resource available to open the channel. 
5 34. Apparatus according to any of claims 23-33 wherein the sequence of the data packets 
conqsrises real-time multimedia data. 

35. Apparatus accordmg to claim 34, wherein the multimedia data con5>rise video data. 

36. Apparatus according to claim 34, wherein the multimedia data comprise voice data. 

37. Apparatus according to claim 36, wherem the fibrst transceiver con5)rises a telephone 
10 ad^ter, which is configured to exchange the voice data m the form of analog audio signals to 

and fiom a telephone handset. 

38. i^aratus according to claim 36, wherein the first transceiver conq>rises a con^uter 
conmiunication port, which is configured to exchange ttie voice data in the form of voice 
packets to and firom a voice qsplication on the personal con5)uter. 

15 39. i^paiatus according to any of claims 23-33, wherein the connectionless real-time 
protocol comprises a Real-time Transfer Protocol (RTP). 

40. Apparatus accordmg to any of claims 23-33, wherein the first transceiver comprises 
one of a subscribe: transceiver in a subscriber premises, and a concentrator, and wherein ttie 
electric power line is a part of a mains voltage power line network to which the subscriber 

20 transceiver and the concentrator are coimected. 

41. Communication ^paratus, comprising: 

a subscriber transceiver, for deployment in a subscriber premises, the subscriber 
transceiver being adapted to be coupled to an electric power line belonging to a mains voltage 
power line network; and 

25 a concentrator, coupled to the power line network so as to convey data between the 

subscriber transceiver and a packet communication trunk, the subscriber transceiver and the 
concentrator being configured to establish a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
the sequence belonging to a session of a connectionless real-time network protocol, the 

30 subscriber transceiver and the concentrator are adapted, responsive to a first packet in the 
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sequence, to establish a reliable connection channel for the session over the data link and to 
transmit the packets in the sequence &om one to another over the reliable connection channel. 

42. Apparatus according to claim 41, wherein the sequence of tho data packets comprises a 
real-time data ftow to be conveyed between the subscriber premises and a networic server via 

5 the packet communication trunk. 

43. Apparatus according to claim 42, wherein the real-time data flow comprises telephony 
data, and wherein the networic server comprises a telephony gateway, which is coupled to a 
public switched telephone netwoik (PSTN). 

44. Apparatus according to any of claims 41-43, wherein the subscriber transceiver is one 
10 of aplurality of such transceivers in multiple, respective subscriber premises connected to the 

power line network, and wherein the concentrator is coupled to link afl of flie plurality of the 
transceivers to the packet communication trunk. 

45. Apparatus according to claim 44. wherein the sequence of the data packets comprises 
telephony data associated with a telephone call placed from one of the multiple subscriber 
premises connected to the power line networic to another of the multiple subscriber premises, 
and comprising a telephoi^ gateway, coupled to lie packet communication trunk, which is' 
configured to serve as a virtual exchange, so as to convey die telephony data from the one of 
the subscriber premises to the other wiflxout sending the data through a pubKc switehed 
telephone netwoik (PSTN). 

20 46. Apparatus according to claim 45. wherein when the telephony gateway is further 
coiq,led to the PSTN so as to convey telephone communications between flie PSTN and the 
multiple subscriber premises. 
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